collection

3.4. TC CALDAV

Work over last 4 months:

  • Scheduling Drafts — Worked designing on a mechanism for creating drafts of scheduling objects which allows event/tasks to be created without automatic scheduling operations being performed by the server until the organizer “commits” the draft as ready for scheduling. The current design is as follows:

    • Drafts are stored as resources in calendar collections using a specific DAV:resourcetype value (NOT in a single “drafts” collection)

    • To create a draft: POST /;add-member — server returns location of created draft

    • To “commit” a draft: POST //?action=create — server deletes the draft and adds a new non-draft resource (it may use the same URI/UID or a different one — location is returned)

    • Open issue on how to specify draft DAV:resourcetype at creation time — three possibilities:

      1. Use a query parameter on the POST URL, e.g. ?resourcetype=calendar-draft

      2. Use a header field in the POST request, e.g. DAV-resourcetype: calendar-draft

      3. Use a multipart media type for the POST body that combines PUT+PROPPATCH to do atomic setting of WebDAV properties and resource body all in one go, e.g. “multipart/webdav-resource” with the first part being application/xml (WebDAV PROPPATCH body) and the second part being the data for the resource body.

    • A mechanism for creating drafts from existing events was discussed and tabled as future work

  • Server Information Document (Rich Capabilities) — Worked on designing a structured resource to organize the DAV services and features available on a server to replace the already bloated DAV response header field. The current design is as follows:

    • The resource will be an XML document containing elements describing one or more “services”, e.g. CalDAV, CardDAV, generic WebDAV

    • Each “service” element will contain elements describing one or more “features” of that service, e.g. DAV level 1, calendar-access, sharing, etc

    • Open issue on how to list DAV features present in all services — two possibilities:

      1. List global “features” at the top of the XML document outside of any “services”

      2. List the global “features” inside a specially named “service”, e.g. “*”

    • A mechanism for including global/constant-valued DAV properties was discussed and tabled as future work

Work for the next four months:

  • How to handle visibility of drafts by non-draft-aware clients? Keep resource-type as calendar?

  • More ioptesting on managed attachments, especially attachments on recurrences

  • Make managed attachments spec depend on server info document — probably requires revisiting including global/static/constant properties

  • Move WebDAV Prefer through IETF

  • Generate a client/server capability matrix for publication